Mobile ticketing

ABSTRACT

Embodiments of a transit ticket system are provided. The transit ticket system may include a mobile computing device configured to (i) download a mobile ticketing application from a ticket management server, the mobile ticketing application including a graphical data sheet, a ticket dictionary, and ticket strings, (ii) receive ticket rendering instructions from the ticket management server in response to completion of a ticket purchase process via the mobile computing device, and (iii) render for display an active ticket on the mobile computing device with data stored on the mobile computing device based on the ticket rendering instructions, the graphical data sheet, ticket dictionary, and ticket strings in response to an activation input command.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/744,886, filed Oct. 3, 2012 entitled “MOBILE TICKETING” theentire contents of which are hereby incorporated herein by reference forall purposes.

FIELD

The present disclosure relates generally to apparatus, systems andmethods for transit mobile ticketing.

BACKGROUND AND SUMMARY

Transit agencies typically issue traditional paper tickets that may bevalidated once a rider boards a bus, train, or other transportation modeoperated by the transit agency. The widespread use of mobile computingdevices, such as smart phones, has provided an additional platform onwhich transit tickets may be issued. However, the technology forimplementing such mobile transit tickets may be costly, unreliable, andinefficient.

The inventors have recognized these problems and developed a transitticket system including a mobile computing device configured to (i)download a mobile ticketing application from a ticket management server,the mobile ticketing application including a graphical data sheet, aticket dictionary, and ticket strings, (ii) receive ticket renderinginstructions from the ticket management server in response to completionof a ticket purchase process via the mobile computing device, and (iii)render for display an active ticket on the mobile computing device withdata stored on the mobile computing device based on the ticket renderinginstructions, the graphical data sheet, ticket dictionary, and ticketstrings in response to an activation input command. In this way, thelocal application is able to render and present the ticket for useregardless of the mobile device's connectivity with the ticketmanagement server. As a result, the user can use the ticket in offlinelocations, including tunnels, out-of-range locations, etc.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter. Furthermore,the claimed subject matter is not limited to implementations that solveany or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE FIGURES

FIGS. 1 and 2 schematically show an overview of the transit ticketsystem of the present disclosure, including a rider application, ticketoperations management system (TOMS), and fare inspector.

FIG. 3 schematically shows an overview of the fare inspector of FIG. 2.

FIG. 4 schematically shows an overview of the rider application of FIG.2.

FIG. 5 schematically shows an overview of the tickets operationmanagement system of FIG. 2.

FIGS. 6-8 are flow diagrams illustrating example processes forpurchasing tickets using the transit ticket system of FIG. 2.

FIGS. 9-10 schematically show an example registration system of thetickets operation management system of FIG. 2.

FIGS. 11-15 show exemplary graphical user interfaces of an analyticsfunction of the tickets operation management system of FIG. 1.

FIGS. 16-27 show exemplary graphical user interfaces of a ticketingfunction including the Ticket Designer of the tickets operationmanagement system of FIG. 1.

FIGS. 28-32 show exemplary graphical user interfaces of an enforcementfunction of the tickets operation management system of FIG. 1.

FIG. 33 shows an exemplary graphical user interface of a promotionfunction of the tickets operation management system of FIG. 1.

FIGS. 34-44 show exemplary graphical user interfaces of the riderapplication of FIG. 1.

FIGS. 45-47 show exemplary graphical user interfaces for purchasingtickets using the tickets operation management system of FIG. 2.

FIGS. 48-50 show exemplary mobile transit tickets including embeddedadvertisements according to the disclosure.

FIGS. 51-55 show exemplary graphical user interfaces of an inventorymanagement system according the disclosure.

FIG. 56 shows a method for installing and launching a rider application.

FIG. 57 shows a method for purchasing a ticket via a transit ticketsystem.

FIG. 58 shows a method for downloading a ticket via a transit ticketsystem.

FIG. 59 shows a method for using a ticket via a transit ticket system.

FIG. 60 shows a method for updating validation changes in the riderapplication.

FIG. 61 shows a method for using a ticket via a rider applicationexecuted on a mobile computing device.

FIG. 62 shows a method for issuing citations via a mobile device of aticket inspector.

FIG. 63 shows a method for downloading a ticket.

FIG. 64 shows a method managing a transit ticket system.

FIG. 65 shows a method for gathering analytic information from a transitticket system.

FIGS. 66-68 show example graphical user interfaces which may bedisplayed by an inspector application.

FIG. 69 shows an example process flow for managing tickets via multipledevices.

FIG. 70 shows a graphical user interface executed via a mobile ticketingapplication on a mobile computing device.

FIG. 71 shows a process flow for purchasing a ticket via a networkbrowsing application and downloading the purchased tickets via a mobiledevice.

FIG. 72 shows an example ticket design interface.

FIG. 73 shows a depiction of the functionalities of the rules engine.

DETAILED DESCRIPTION

Aspects of this disclosure will now be described by example and withreference to the illustrated embodiments. Components and other elementsthat may be substantially the same in one or more embodiments areidentified coordinately and are described with minimal repetition. Itwill be noted, however, that elements identified coordinately may alsodiffer to some degree. It will be further noted that the drawingsincluded herein are schematic and generally not drawn to scale. Rather,the various drawing scales, aspect ratios, and numbers of componentsshown in the figures may be purposely distorted to make certain featuresor relationships easier to see. Therefore, the figures are not intendedto be technically precise, but are drawn to ease understanding.

Embodiments are disclosed herein relating to creating, managing, anddispersing mobile transit tickets. The transit ticket system may includea rider application configured to operate on a mobile device of a user,a tickets operation management system to create, allocate, and dispersethe transit tickets, and a fare inspector system for validating thetickets. The rider application may be more generally referred to as amobile ticketing application. FIGS. 1 and 2 schematically show anoverview of the transit ticket system of the present disclosure,including a rider application, ticket operations management system(TOMS), and fare inspector. Each component of the transit ticket systemis illustrated in greater detail in FIGS. 3-5, in which FIG. 3schematically shows an overview of the fare inspector, FIG. 4schematically shows an overview of the rider application, and FIG. 5schematically shows an overview of the tickets operation managementsystem. It will be appreciated that TOMS may include a ticket managementserver. Additionally, it will be appreciated that the fare inspector mayinclude an inspector application executed on a mobile computing device.Furthermore, the rider application may be in electronic communicationwith the ticket management server via a network (e.g., the Internet, awide area network (WAN), local area network (LAN), etc.).

The transit tickets may be created by the tickets operation managementsystem using a Transit Ticket Designer that receives input from a userindicative of one or more images the user desires to include as part ofthe ticket design. The Ticket Designer provides a platform in which theuser may change multiple aspects of the images, including color,position, and animation, in order to create an individualized transitticket. The ticket may then be stored and, upon a request from themobile device of the user, be made available for rendering on the user'smobile device. The rendered ticket may then be presented when the userboards a transit vehicle. FIGS. 6-8 illustrate example processes forregistering a user and purchasing tickets using the transit ticketsystem of the present disclosure. FIG. 6 shows a first time userpurchase scenario. FIG. 7 shows a registered user purchase scenario. Thepurchase scenario shown in FIG. 7 assumes that the user is logged in andhas a registered account in the system. FIG. 8 shows a quick purchasescenario for a registered user. The purchase scenario shown in FIG. 8assumes that the user is logged in and has a registered account in thesystem.

As shown in FIGS. 6-8, the ticket purchase may be implemented via amobile device in the transit ticket system. However, other suitablecomputing devices may be used to purchase tickets. For instance, ticketsmay be purchased via a network browsing application executed on adesktop device. When the user buys tickets via a mobile ticketingapplication they may add tickets to a shopping cart. It will beappreciated that the mobile ticketing application may require a user tolog-in or register if they do not have an existing account. After a userselects checkout, after selecting one or more ticket for purchase, theymay be prompted to enter payment information (e.g., a credit cardnumber) or selected stored payment information. If the user is enteringnew payment information they may be given the choice of registering thepayment information for quick future use. After the payment informationis confirmed tickets may be downloaded and stored in the mobile device.

FIGS. 9 and 10 illustrate an example user registration screen that auser may be presented with when registering to use the transit ticketsystem. Rather than utilizing quick response codes (QR codes) or otherbarcode identification mechanisms which may be scanned by a device onthe transit vehicle, the transit tickets of the present disclosure mayutilize visual identifiers that can be quickly recognized by employeesof the transit agency, such as operators of the transit vehicles, inorder to validate the tickets. In doing so, the installation ofhigh-cost scanning devices onto each transit vehicle may be dispensedwith. However, in some embodiments, QR codes may be displayed with thetransit tickets in order to allow the transit agency to scan the transittickets to confirm validation. Furthermore, the transit tickets may beconfigured to change in visual appearance based on a location of theuser, day of the week, type of transit ticket purchased by the user,etc., in order to provide additional security and reduce the likelihoodthat the transit tickets may be copied by non-paying individuals. In oneexample, the screens shown in FIGS. 9 and 10 may be presented in asequential manner. Thus, the screen shown in FIG. 10 may be displayed inresponse to user input entered into the screen shown in FIG. 9.

In addition to providing a system for designing transit tickets, thepresent disclosure may also provide for embedding clickableadvertisements into the transit tickets. Additional information may alsobe provided along with the transit ticket when the user requests aticket in order to board a transit vehicle. For example, informationregarding the user's location, approximate wait time until a desiredtransit vehicle arrives, etc., may also be presented with the ticket.Further, a virtual inventory management system may be provided toallocate, track, and reconcile the issuance of the transit tickets.

The ticket operations management system (TOMS) may enable administratorsto interact with the system and create custom tickets, connect withcustomers, track activity, and enhance operations. The TOMS may beconfigured to track mobile ticket sales and transactions and ties thosereports into an existing accounting system. Using the geo-analyticsplatform and time slider, you can view activity on a map for aparticular period, and better understand who is buying and using mobiletickets, where and when. Additionally, the TOMS may include variousfunctions accessible to a user (e.g., an administrator) through agraphical user interface, including but not limited to an analyticsfunction, illustrated in FIGS. 11-15. The analytics function may providevarious statistics on user ridership, such as overall number of ticketspurchased, most popular transit line, etc.

Specifically, FIG. 11 shows an analytics dashboard which may include anoverview tab, a line statistics tab, a rider statistics tab, and aticket statistics tab. The analytics dashboard may be presented on adisplay of a computing device included in the TOMS of the transit ticketsystem. The line statistics tab may include an interactive systems map.The map may be filtered by transit type (e.g., bus, rail, etc.).Additionally, the map may include a heat map which may showconcentration of ridership, ticket activation, ticket purchases, etc.,graphically depicted where individual values are graphically representedvia colors. Other map functions may include a show/hide icon button, adate range, a time range, a default setting, a zoom in/out button, ahover over lines for quick information functionality, and/or a data panerepresenting a selected map graphic such as a line, zone, and/or area oftown. The line statistical data displayed via the analytics dashboardmay include transit type, total number of riders by transit type,most/least used lines, and/or peak/minimum/average ridership for all thebus/rail lines. Additionally, analytical data which may be displayed onthe dashboard may include total sale by fare/rider type, total number ofriders by fare/rider type, peak/minimum/average ridership, ridershippercentage trend, rider satisfaction, number of scan approved/rejected,number of new/returning users, and/or lucrativeness rating for a singlebus/train line.

A rider statistics tab may also be displayed on the dashboard shown inFIG. 11. The rider statistics dashboard may communicate bothquantitative and qualitative data about the behaviors, patterns,perceptions of commuters using the mobile ticketing application. Thedata sets may include:

a.) The users in the system (e.g., the new vs. returning users includinga breakdown of number of rides and frequency of riding for returnusers).

b.) Total, peak, base, and/or average volume of ridership per day, hour,minute.

c.) Breakdown of riders by type (e.g., adult, youth, etc.).

d.) Overall ridership increase/decrease percentage since previoustimeframe.

e.) How long after purchase riders activate tickets (wouldvalidate/contradict the assumption that most people are buying rightbefore boarding).

f.) Rider sentiment (e.g., as submitted through the ticketingapplication), both overall and filterable by specific meta-data (e.g.,line, time of day, stop, etc.).

g.) Social media feed pulling keywords, hash tags, etc., from anapplication program interface (API).

h.) Wordle based on aforementioned social media feed (e.g., a prevalencetag cloud).

i.) Overall brand health—% breakdown of satisfaction and overallsentiment as expressed via the in-app satisfaction rating and comments,as well as social media culling.

The ticket statistical tab may include statistical data relating to allthe tickets in the system. The data may include:

a.) Total number of tickets purchased with ability to filter by fare,rider, or a combo of both.

b.) Ridership spending—Total ticket sales with same filter ability asabove.

c.) Number of tickets used (with ability to see when/where, as well ashow many are currently activated).

d.) Most activated ticket types in descending order.

e.) Frequency of individual ticket vs. multiple tickets activation.

f.) Number of people who purchase a single-use ticket (e.g., day ticket,2 hour ticket) vs. a bundle (e.g., 7 day ticket, month ticket, yearticket, etc.).

g.) Purchase frequency heat mapping by date or location.

h.) How quickly riders activate a ticket after purchasing.

i.) How quickly riders activate a ticket after purchasing.

j.) Number of fare operator check-ins (e.g., all, approved, rejected)with associated meta-data (e.g., line, inspector, time of day, tickettype, etc.).

k.) Ticket sales in application vs. online.

l.) Order history.

FIG. 12 shows various analytical data presented in a window vianumerical, values, graphs (e.g., pie graphs, bar graphs, etc.). FIG. 13shows an example analytics map including map filters such as tickettype, user type, etc. It will be appreciated that in one example thewindows shown in FIGS. 12 and 13 may be accessed via a network browsingapplication such as a web-browser on a computing device in the transitticket system.

FIG. 14 shows a sales report presented in an example window of ananalytics dashboard in the transit ticket system. The sales report mayinclude various data such as serial number, a portion of social securitynumbers, date of purchase, date of launch, fare type, value of fare,and/or payment type.

The TOMS may also include a ticketing function illustrated in FIGS.16-27 and an enforcement function, illustrated in FIGS. 28-32.Specifically, FIGS. 28-32 show a dashboard including enforcement dataincluding a list view tab of enforcement data such as device, inspector,line, scan time, scan status, scan method, rider, and fare zone.Enforcement analytics may also be displayed in the enforcementdashboard. The enforcement analytics may include total number ofinspections (e.g., all, passed, rejected, scan, SMS), inspector stats(e.g., most/least scans), and/or scan statistics and trends by line,time of day, day of week, and ticket type.

The TOMS may also include a promotions function illustrated in FIG. 33.Additionally, the TOMS may include a loyalty function tab which maydisplay a list of system users qualifying for loyalty program benefits,a list of system users on the cusp of qualifying, and who has takenadvantage of loyalty customer program benefits. The loyalty tab may alsoenable management of push notifications to users qualifying for loyaltyprogram benefits, and/or management (e.g., creation) of benefits and/orrules/terms.

The ticketing function, which will be described in more detail below,may provide a platform for the transit agency to design and distributetickets, and/or may provide a platform for the user to purchase andcreate tickets. The enforcement function may provide data regarding thenumber of validated tickets, mechanism of validation, and otherinformation. The promotion and loyalty functions may provide fortracking user ticket purchases in order to grant the user variousbenefits. While each function of the ticket operations management systemmay be accessible to all users, in some embodiments certain functionsmay be restricted to a subgroup of users. For example, the enforcementfunction may only be accessible to the transit agency.

TOMS may support the use of various languages, including JavaScript,HTML 5, CSS, SQL, Objective C, Java, and PHP, implemented by varioustools, such as Titanium Studio (Eclipse), XCode, Dreamweaver, and JIRA.

As explained above, the ticketing function of the TOMS may include aTransit Ticket Designer that provides tools to create transit ticketsthat contain selected animation, color, and design elements.Additionally, these tickets provide an alternative authentication methodto visual authentication via QR Codes. These QR Codes are created usingmeta-data associated with the ticket and activities relating to theticket (i.e., purchased, used, scanned).

The Ticket Designer provides the ability to upload a grouped set ofimages to create a transit ticket. Once a set of images is chosen, eachof the images and their associated properties (color, height, width,etc.) may be manipulated to create a unique looking ticket. In additionto changing the look of the images, the images may also be placed atspecific locations with a frame (e.g., HTML canvas) when the image isrendered and then moved (via animation) to new specific locations at agiven speed. Once a ticket is rendered, an encrypted QR Code may begenerated using meta-data about when the ticket was purchased and/orvalidated, along with information about the rider and the ticket type.

Example graphical user interfaces of the ticketing function includingthe Ticket Designer are illustrated in FIGS. 16-27. As previouslydiscussed the Ticket Designer is included in the transit ticket system.FIGS. 16-21 illustrate example graphical user interfaces available tothe user when viewing existing tickets in the transit ticket system.

The user may edit the appearance of the tickets by adjusting animation(as illustrated in FIGS. 16-17), color and/or font of images or text onthe tickets (as illustrated in FIG. 18), and/or other parameters. In oneexample, the graphical user interfaces shown in FIGS. 16-28 may bepresented in a sequential manner based on user input into theinterfaces.

The user may adjust the ticket design on a one-time basis, or may adjustthe tickets periodically, as illustrated in FIGS. 19-21. For example,FIG. 20 shows an example graphical user interface that includes grayedout portions with dialog boxes overlaid on the grayed out portion. Inone example, anything grayed out on the interface of FIG. 20 only showsif the user selects an associated radio button (so weekly specificationinformation only shows up if the user selects the weekly radio button).If the user selects Weekly, they may not have the option to specifycolor changes for each week—it may be random by default. So when theuser clicks Next, he or she would get the message box illustrated offscreen right. If the user selects Monthly, he or she will get theinterface shown on FIG. 21. Also, choosing every year may not requireany sort of date selection, and thus is illustrated here as a lone radiobutton. Every year may be a random color change as well. In anotherexample, FIG. 21 shows a schedule option for ticket design updates.Herein, the monthly drop-downs only display months that will be affectedaccording to the frequency and start date specified in the previousstep. So if the user selects every other month starting in March, themonths would be March, May, July, September, and November. In oneexample, the graphical user interfaces shown in FIGS. 19-21 may bepresented in a sequential manner based on user input into theinterfaces.

FIGS. 22-24 show various tabs in a ticketing dashboard in the transitticket system. The view/edit tickets tab may enable a user to view andedit existing ticket data such as title, rider class, time class,geographical class, price, ticket design, ticket animation, etc. The“create new ticket” tab enables a user to create new tickets which maydefine one or more of the aforementioned ticket data fields. The defineticket attributes tab may enable a user to define new rider classes(e.g., adult, youth, honored citizen, paratransit, etc.), time classes(e.g., 2 hour, day, week, month), and/or geographical classes (e.g., allzone, 1 zone, 2 zone, 3 zones, etc.). In one example, the graphical userinterfaces shown in FIGS. 22-24 may be presented in a sequential mannerbased on user input into the interfaces.

FIGS. 25-27 illustrate graphical user interfaces of the Ticket Designershowing previously-designed ticket options to a user, which he or shemay select. In one example, the graphical user interfaces shown in FIGS.25-27 may be presented in a sequential manner based on user input intothe interfaces. FIGS. 25-27 further illustrate options presented to auser for modifying selected tickets. One example process for creating aticket using the Ticket Designer according to the present disclosureincludes:

1.) The art components are created. The art components include but arenot limited images, text, and animations.

2.) The components are loaded into the spritesheet maker. This loads allcomponents as images and then draws them to a canvas element, and keepstrack of the rect (x, y, width, height) that each component occupies,and each component's name.

3.) The rect and names are then compiled into a dictionary object, whichis then sent to a server and stored in a database.

4.) A user then launches the Ticket Designer and specifies whichspritesheet to use and the Ticket Designer asks the server for thedictionary.

5.) The components are laid out in the Ticket Designer and the user mayuse the design tool to layout the components, change the color of one ormore of the components, and/or apply animation.

-   -   i.) To layout the components, the Ticket Designer utilizes a        canvas element and updates a component's rect by tracking mouse        movement (e.g., movement of the user's mouse) within the canvas.    -   ii.) To change a color of a component, the canvas grabs the        pixel data for the component and then changes the RGBA values        based on user input.    -   iii.) At least four types of animations may be used, including        velocity, scaling, rotation, and opacity. All rotations allow        for repeat values, with −1 being constantly repeating, a delay,        and a “ping-pong,” meaning the animation will be run forward and        then backward.        -   a.) Velocity animations have a user set a start point, end            point, and a duration. The Ticket Designer then calculates            the x-component and y-component of the component's velocity            based on the duration and the delta between x and y values            from the start point to the end point.        -   b.) Scaling animations have a user set a start scale, an end            scale, and a duration and calculates a step based on the            duration to add or subtract from the current scale (with 1.0            as the base scale).        -   c.) Rotation animations have a user set a start rotation, an            end rotation, and a duration, and a step number of radians            is calculated for each iteration of the animation.        -   d.) Opacity animations have a user set a start opacity, an            end opacity, and a duration. A step is calculated for            opacity based on duration.

6.) The Ticket Designer allows for previewing of the ticket as a whole.

7.) Once the ticket has been created, the user submits the ticket to theserver as a string representing the ticket object.

-   -   i.) The ticket object is an array of objects called layers with        an additional object containing data specific to the ticket.    -   ii.) The first index in the array has the name of the        spritesheet image used for the tickets.    -   iii.) Subsequent indices are the layers of the ticket.        -   a.) Each layer has the color of the ticket as RGBA values.        -   b.) Each layer has the name of the component used for the            layer.        -   c.) Each layer has the starting position of the layer.        -   d.) Each layer has an array of animation objects.            -   I.) Each animation object has the type of animation.            -   II.) Each animation object has the beginning parameters,                ending parameters, duration, repeat, delay, and ping                pong values.

8.) A rider (e.g., the user) purchases a ticket and a new ticket entryis created in the databases with a reference to a previously submittedticket design.

9.) The rider application on the rider's computing device (e.g., smartphone, tablet, laptop computing, etc.) downloads the ticket object aswell as any relevant information it may not have i.e. spritesheet anddictionary.

10.) The application creates three canvas elements, one that is a firstbuffer for individual components, a second that is a buffer for thewhole ticket, and the third which renders the ticket.

11.) The application loads the spritesheet into an image element thendraws those to the first buffer and then grabs the pixel data from thatcanvas for each layer in the ticket.

12.) After the layer components, the application renders the textcomponents that display ticket information like expiration, rider type,and daycode.

13.) The top unanimated layers are all combined into a single layer toassist performance.

14.) Once all components have been loaded, the application draws themonto the first canvas based on their rect and then puts the image dataof the first buffer onto the second buffer. Once all components havebeen drawn to the second buffer, the context for the third canvas isadjusted to fit the proportions of the rendering screen and thecompleted ticket image is drawn to scale to the screen.

15.) All animations created with the parsing of the ticket object arenow started and an interval is called to update the state of the ticketand then render the ticket via the process in step 13.

16.) When the QR button is pressed a QR code is generated usingencrypted text with information about the ticket and given an opacityanimation in order to fade in and out.

17.) This QR code is added as an additional layer to the end of theticket object.

Another example process for creating and/or editing a ticket using theTicket Designer according to the present disclosure includes:

1.) The Ticket Designer allows for users to create and edit designs forvisually authenticated tickets. The creation of tickets may use avariety of predefined elements from a supplied library, or new assetsthat the user uploads. These designs can be used for transit, events,and advertisements.

2.) Upon loading, the Ticket Designer may consult a Rules Engine topopulate a library of predefined assets.

3.) User selects assets to use in the project.

4.) A graphical data sheet (e.g., spritesheet), ticket dictionary, andticket object are created referencing this collection of assets. Theseare stored in the Rules Engine.

5.) The user will then have the ability to upload new components, suchas text or images, which will then update the graphical data sheet(e.g., spritesheet), ticket dictionary, and ticket object.

6.) Each component is drawn to a canvas, rendering the ticket.

7.) A menu of layers is populated from each component. Each layercontains references to initial properties that can be edited.

8.) Users add ticket states (e.g. tapped/untapped screen). This updatesthe ticket object.

9.) Users select a layer to edit from the menu. If applicable user canselect which state to edit.

10.) Users can edit multiple properties of the selected layer.

11.) Through mouse or keyboard manipulation, which will update theticket object.

12.) The user adds or edits animations. This can be done by modifyingvalues within each layer's menu, or by modifying the animation timeline.The timeline features a visual reference to the speed and duration ofeach animation.

13.) Saving the ticket encrypts the graphical data sheet (e.g.,spritesheet), ticket dictionary, and ticket object.

14.) Encrypted information is sent to the rules engine for storage.

15.) The new ticket can be edited at a later time by loading the ticketfrom the Rules Engine, or can be scheduled to use at a specific time ordate using the Ticket Scheduler.

Example graphical user interfaces that may be presented to a user wheninteracting with the rider application are illustrated in FIGS. 34-43.In one example, the graphical user interfaces shown in FIGS. 34-43 maybe presented in a sequential manner based on user input into theinterfaces.

The rider application may provide a user with the ability to purchase aspecific transit ticket for a particular rider as well as allow the userto display the purchased ticket on his or her mobile device forvalidation. For example, FIG. 34 illustrates the rider application asviewed on a user's mobile device home page as well as the user interfacepresented when the application is launched. FIG. 34 illustrates userinterfaces presented to the user during login. FIG. 35 illustrates auser interface of the rider application displaying a buy tickets page.This interface may be how the buy ticket page looks the first time auser uses the rider application. The first step is to select the ridertype. FIGS. 36 and 37 show the rider application buy tickets screen whenthe user has selected the rider type as “Adult.” The application startsto populate the ticket into the buy tickets page.

FIG. 38 illustrates the next step in the ticket purchase process, wherea prompt is displayed for the user to select a fare type. In theillustrated example, a Month pass has been selected. The applicationpopulates a complete Adult Month pass in the buy tickets cart. FIG. 39shows an example of how a user can purchase multiple tickets at once. Inthis example, the user is adding a Youth ticket type. FIG. 39 also showsthe buy tickets page as ready to check out. After selecting the faretype, a Youth 2 Hour ticket populates into the buy tickets cart. Theuser in this example has added another Youth 2 Hour ticket by selectingthe quantity button to the right of the ticket. The total adds up andthe transaction is completed by pressing the green checkout button. Inthis way, the rider may check their purchases prior to checking out.After selecting the checkout button presented on the interface the usermay be prompted to enter payment information. New payment informationmay be entered by the user or existing payment information stored (e.g.,a previously used credit card) on the device may be selected. The usermay be given the option to register their new payment information forfuture use. Further in one example, the user may be alerted if thepayment information has failed and a suggested correction may bedisplayed to the user.

FIG. 40 illustrates a ticket library function of the rider application.After purchasing an Adult Month pass and a Youth 2 Hour ticket, thetickets have been populated as unused tickets in the my tickets page. Itwill be appreciated that the tickets may be downloaded into the “mytickets” tab in response to purchasing the ticket via the interfaceshown in FIG. 39. It will be appreciated that the tickets shown in FIG.40 are ready for use.

After selecting the “use” button, the desired ticket will be validatedand the animated ticket will appear. FIG. 41 illustrates an exampleticket. After selecting the view button for the Adult Month pass, theticket is displayed. The rider may press “Hop On” to launch the animatedticket. It will be appreciated that selecting the use button or the hopon button may trigger activation of the ticket. The activated ticket mayuses various components such as date, time, ticket type, user type,agency, location, animation, sound, video, vibration or images toindicate validity. These components may be stored on the mobile deviceprior to activating the ticket. Additionally, an expired ticket maychange the various components (date, time, ticket type, user type,agency, location, animation, sound, video, vibration or images) andunderlying data to indicate that a ticket has expired. In one example,the brightness of the ticket may be altered to indicate active andexpired states.

FIG. 42 shows an example QR code that may be displayed in response to aselection by the rider. By selecting the QR button, a large, scanable QRscreen displays so that a fare inspector can scan the ticket with theInspector Application. FIG. 43 shows ticket screen displaying active andinactive tickets. After validating the Adult Month pass, it is nowmarked as an active ticket and the expiration date is displayed. It willbe appreciated that the user may have options to select multipletickets. By selecting multiple, the rider can use quantity selectorsalongside the tickets in the my tickets page. If there is more than onetype of ticket, more than one can be selected. It will be appreciatedthat more than one ticket may be simultaneously displayed on the mobiledevice. The top right of the screen displays multiple riders using thisticket.

Thus, FIGS. 34-43 illustrate various graphical user interfaces that maybe presented to the user when the user is purchasing one or more transittickets via a mobile device in the transit ticket system. The user mayhave the option of selecting a type of rider (such as youth, adult, orhonored citizen) and type of fare (2 hour, day, 7 day, 4 day, month), aswell as being able to purchase multiple tickets for multiple riders.Additional information may also be displayed via the rider application,including total amount charged to the user's account when purchasingtickets, the number of tickets purchased by the user, whether purchasedtickets are active or inactive, etc. It will be appreciated that therider application may change in appearance on different types of mobiledevices, and that varying operating systems of the mobile devices may besupported.

FIG. 44 shows an example interface of an inspector application showing apage after a ticket has been validated. It will be appreciated that theinspector application may be included in the transit ticket system. Theinspector application may verify ticket authenticity through phonenumber, scanning the QR code on the ticket displayed on the riderapplication, and/or SMS.

While FIGS. 34-43 show examples of how a user may interact with thetransit ticket system to purchase and use tickets with a mobile device,FIGS. 45-47 illustrate user interfaces a user may be presented with whenpurchasing tickets on a non-mobile device, without using the riderapplication. For example, the user may purchase tickets in advance onhis or her home computer, and these tickets may be saved for latervalidation (for example, the user may call up one or more tickets on hisor her mobile device using the rider application at a later time). Auser may enter a password via a home computer to login to an existingaccount or create a new account. Additionally, the user may select arider type, a fair type, and/or a ticket quantity to purchase a ticketvia a window provided via the ticketing. The aforementioned ticketingoptions may be stored in a cart. A user may also enter billinginformation (e.g., payment information (credit card number, expirationdate, etc.), shipping address, etc.) into fields presented via a networkbrowsing application. The number of ticket orders may also be presentedvia the network browsing application to the user. Furthermore, it willbe appreciated that the ticketing purchasing functionality discussedabove with regard to mobile computing devices may also be provided viaother types of computing devices such as desktop computing devices,laptop computing devices, etc. In one example, the graphical userinterfaces shown in FIGS. 45-47 may be presented in a sequential mannerbased on user input into the interfaces.

Additionally, a ticket purchasing interface may display various buttons,tabs, or other interface objects for purchasing tickets. FIG. 45 showsone embodiment of a ticket purchasing interface. In one example, aticket purchasing interface may be accessed via a desktop device andpurchased tickets may be downloaded to a mobile device. Technical tips,how to videos, help buttons, ticket purchase buttons, my accountbuttons, and/or sign-in fields may be provided in the ticket purchasinginterface. The my account button may trigger display of an accountscreen which may enable a user to enter new account information, if theyare a new user, or change account information if they are not a newuser. The ticket purchase button may trigger display of a purchaseinterface which enables a user to select tickets for purchase. If a useris not signed in when the purchase interface is displayed they may beprompted to sign in.

FIG. 47 further shows additional information that may be available tothe user, whether using the rider application or simply logging in tothe TOMS, such as information on bus arrival time, alerts, etc.

As described above, the Transit Ticket Designer provides tools to createtransit tickets that contain unique animation, color and advertisingdesign elements, and which provide an alternative authentication methodto visual authentication via QR Codes. Additionally, advertising may beembedded in the transit tickets designed by the Ticket Designer. Forexample, FIGS. 48-50 show example mobile transit tickets that includeadvertisements embedded in the tickets.

When a ticket and animation scheme that contain advertising images arechosen, then when a rider enters a geo-fenced area, the rider is alertedto open an active ticket and the animation is activated.

In one example, a process for embedding advertising in a transit ticketincludes performing the steps 1-16 as described above and additionallyincludes:

17.) Once an animation with an embedded advertising is viewed orclicked, then this data is recorded and synced with a server forreporting and analytics.

Thus, the Ticket Designer allows a user to select and/or modify a groupof images to be presented as part of an electronic, mobile transitticket. The transit ticket may then be retrieved by a transitapplication of the user's mobile device when the user wishes to board atransit vehicle. In order to manage the number, type, etc., ofelectronic transit ticket issued by the transit agency, a system,described below, is provided for allocating the tickets.

The Virtual Inventory Transit Ticket system allows for “virtual” ticketsto be allocated by a transit agency. The allocation provides a uniquenumber, the fare type, number of tickets, associated prices, and otherkey data. The virtual inventory system provides a means of financialaccountability for the transit agency and the inventory managementsystem owner. Tickets may be allocated via a web interface or WebServices. FIGS. 51-55 illustrate graphical user interfaces available toa transit agency or other administrator when using the inventorymanagement system described herein.

Each fare type is created as a product type in the inventory system withassociated warning and emergency threshold levels set. A transit agencymanager logs into the system and allocates a number of tickets for eachfare type and sets the threshold limits. When a rider requests a newticket, an allocated ticket of the appropriate fare type is removed frominventory and assigned to the purchasing rider. This movement frominventory to purchased status is tracked via the unique identificationassigned to each allocated ticket.

When the inventory levels of each ticket reach the assigned warninglevel, an email is sent to the transit agency administrator requestingan allocation of additional tickets. If a response is not receivedwithin a specified time period or the inventory level gets to a criticalstage, then another email is sent to a broader team and a pre-set amountof inventory is automatically allocated.

All inventory transactions are reconciled with the payment processorsrecords and the reports are exportable in PDF, CSV and XML format.

FIG. 56 shows a method 5600 for installing and launching a riderapplication via a mobile computing device in a transit ticket system.The method 5600 may be implemented via the mobile computing devicesincluded in the transit ticket system discussed above with regard toFIGS. 1-55 or may be implemented via other suitable mobile computingdevices and/or transit ticket systems.

At 5602 the method includes downloading a rider application from one ormore application stores. Next at 5604 the method includes launching therider application. At 5606 the method includes installing a Spritesheetcontaining ticket images, animation, text, graphics on the mobiledevice. The Sprite Sheet images may be used to provide the visualidentifiers for authenticating the tickets. In some examples, the SpriteSheet may be encrypted to prevent unauthorized access to the images usedfor the visual identifiers.

Next at 5608 the method includes generating a unique ID for the riderapplication. The unique ID associates the rider application with themobile device. At 5610 the method includes capturing mobile deviceinformation. The mobile device information may include screen size anddensity, operating system type, operating system version, and networkcarrier. Additionally, capturing the mobile device information mayinclude storing the mobile device information on the phone file systemfor later retrieval by an application code. At 5612 the method includescreating databases for offline use and analytics. In one example, ticketinformation and user activity may be stored in local and remotedatabases. At 5614 the method includes creating a default productcatalog for storage on the mobile device. At 5616 the method includessetting an update interval that instructs the rider application on thefrequency of validating changes with the server. In this way, the riderapplication may “phone home” periodically to retrieve validation. Itwill be appreciated that the update request may be implementedautomatically without user interaction, in one example. Furthermore, theupdate request may be implemented regardless of the tickets purchasedvia the rider application, in one example.

FIG. 57 shows a method 5700 for purchasing a ticket via a transit ticketsystem. The method 5700 may be implemented by the transit ticket systemdescribed above with regard to FIGS. 1-55 or may be implemented by othersuitable transit ticket systems.

At 5702 the method includes selecting a valid rider type. Next at 5704the method includes selecting a valid fair type. The valid rider typeand/or valid fair type may be selected from an installed product catalogon the mobile device.

At 5706 the method includes checking out by selecting a valid paymentinstrument or providing payment information. Next at 5708 the methodincludes verifying inventory is available on the server. In this way, itis assured that inventory is available.

At 5710 the method includes processing payment with a processor. In oneexample, the payment may be processed via a PCI compliant API or otherknown payment system. Next, at 5712, the method includes generating aticket at the server. Generating a ticket may include creating a ticketrecord. At 5714 the method includes updating the inventory with thepurchased ticket. Updating the inventory may include assigning a serialnumber to the ticket for inventory, in one example.

At 5716 the method includes retrieving ticket meta-data from the server.The meta-data may include latest designs such as colors, animationschemes, etc. Such meta-data may be added to the Sprite Sheet. Next at5718 the method includes updating a user account with ticket(s) purchaseinfo and meta-data. The meta-data may be stored on the local mobiledevice as part of the application. Thus, with purchase, the ticket maybe rendered based on the mobile device application. Additional dataexchange with a server is not necessary.

FIG. 58 shows a method 5800 for downloading a ticket via a transitticket system. The method 5800 may be implemented by the transit ticketsystem described above with regard to FIGS. 1-55 or may be implementedby other suitable transit ticket systems.

At 5802, the method includes downloading ticket information to themobile device which may be considered part of the purchase. In someembodiments, an application refresh may further be provided.Additionally, the application refresh may be initiated during a loginprocess and/or via a pull-to-download feature, in one example. Inanother example, the downloaded ticket information may be encrypted andstored in a database in the mobile device. Next at 5804, in someexamples, the method includes storing ticket meta-data (e.g. if therehave been changes) on the mobile device.

At 5806 the method includes updating the server with the downloadinformation. In one example, the download information may includedate/time, latitude, longitude, and/or app ID associated with the mobiledevice. Next at 5808 the method includes determining ticket parametersand storing the ticket parameters in the device. The ticket parametersmay include a HTML canvass positioned, image colors, animation duration,animation path, and/or animation speed. The ticket parameters may beused to dictate how a ticket looks and acts upon activation (e.g.,ticket launch). Additionally in one example, ticket meta-data, such asticket type, may be analyzed to determine expiration times, isotypes,and appropriate informational and warning messages. The meta-data,expirations times, isotypes, informational messages, and/or warningmessages may be stored in the local database. As noted above, thisdownload may occur during purchase, at a set interval after purchase orat another time.

FIG. 59 shows a method 5900 for using a ticket via a transit ticketsystem. The method 5900 may be implemented via the transit ticket systemdescribed above with regard to FIGS. 1-55 or may be implemented viaother suitable transit ticket systems.

At 5902 the method includes tapping a use button in the riderapplication to begin using a ticket. It will be appreciated that therider application may be executed via a mobile device. Additionally,tapping the use button may mark the ticket as validated, in one example.

Next at 5904 the method includes capturing key ticket information andstoring the information locally. The key ticket information may includevalidation date/time, latitude, and/or longitude and may be stored in alocal database in the mobile device. It will be appreciated that the keyticket information may be used during the generation of a QR code.

At 5906 the method includes reading ticket meta-data and launchingticket animation. Reading the ticket meta-data may initiate retrievaland/or display of a ticket expiration time, ticket type, rider type,DayCodes, and ticket name. Images from the Sprite Sheet may be displayedas visual identifiers.

At 5908 the method includes adjusting the ticket canvass based on devicecapability. For instance, the size of the displayed ticket and/oranimation sequence may be adjusted based on mobile device features, suchas a screen size, operating system version, screen density, etc.

At 5910 the method further may include clicking a Daycode button and at5912 the method includes generating a QR code in response to clickingthe Daycode button. The QR code or other code which may be generatedwhen the user taps a DayCode button via the rider application. The QRcode may be encrypted, in one example. Furthermore, the QR code may begenerated using ticket meta-data such as validation date/time, tickettype, rider type and validation latitude and longitude.

As provided above, information such as the Daycode or meta-data may besent to the mobile device on a pre-set schedule or other schedule. Forexample, the system may update the Daycode and meta-data information ona 72 hour schedule or other select schedule. Such updates may beautomated and/or preset and may occur without request or selection bythe user.

Again, it should be appreciated that use of the ticket and presentationof the ticket and visual identifiers may be based on the pre-loadedinformation which occurred during purchase. In such examples, no datafiles or other information needs to be sent to the local applicationafter purchase for use of the ticket. Instead, the local application isable to render and present the ticket for use based on the purchaseinformation. Such an example enables a user to use the ticket in offlinelocations, including tunnels, out-of-range locations, etc.

FIG. 60 shows a method 6000 for updating validation changes in the riderapplication. The method 6000 may be implemented via the transit ticketsystem described above with regard to FIGS. 1-55 or may be implementedvia other suitable transit ticket systems.

At 6002 at the rider application, reading the update interval value andsecurely calling the server to check for validation updates. The riderapplication may provide information regarding the version of theapplication and the time and date of the last update. At 6004 it isdetermined if updates are available at the server. It updates are notavailable (NO at 6004) the method ends. However, if updates areavailable (YES at 6004) the method proceeds to 6006. At 6006 the methodincludes automatically downloading data objects, meta data, images,etc., to the mobile device without any user interaction. At 6008 themethod includes applying the update to the rider application. It will beappreciated that information needed to place ticket images in exactpositions on the HTML canvass, determine image colors, animationduration, animation path, and/or animation speed is stored on the mobiledevice. This information dictates how the ticket looks and acts uponactivation (e.g., ticket launch). This information may be downloaded tothe mobile device during a ticket purchase or when the rider applicationis installed.

FIG. 61 shows a method 6100 for using a ticket via a rider applicationexecuted on a mobile computing device. It will be appreciated that therider application may be referred to as a mobile application. The method6100 may be implemented via the transit ticket system described abovewith regard to FIGS. 1-55 or may be implemented via other suitabletransit ticket systems.

At 6102 the method includes starting the rider application and at 6104the method includes searching for purchased tickets during applicationloading. Next, at 6106 the method includes selecting a ticket for usevia an input command. The input command may be a voice command, aninteraction with a visual component displayed in the mobile device, alaser scan, a command sent via a remove device (e.g., a Bluetoothcommand). Specifically in one example, the user may select a “mytickets” button displayed via the mobile ticketing application and a“use” button via the mobile ticketing application. This functionalitymay be implemented regardless of network connectivity of the mobiledevice. In one example, a user may be prompted with a confirmation alertin response to selection of a “use” button. The confirmation alert mayask the user if they are sure they want to use the ticket and provide ayes or no response choice via the user interface.

At 6108 the method includes retrieving ticket data and coupling theticket data with ticket visualization instructions to render a validticket. The ticket data may include ticket type, user type, and/or othertokens stored on the mobile device. The ticket data may also includeexpiration time. Step 6108 may also include grabbing a lowestidentification of the type of ticket used, checking if a daycode iscurrent (if not update), grab ticket string, decode ticket string, grabuser location, and/or caching the ticket data for re-launching, in oneexample. It will be appreciated that the data generated or retrieved inthe aforementioned steps may be sent to the ticket management serverwhen network connectivity is available. Further in one example, if auser modifies the time on the mobile device the mobile ticketingapplication may send a message to the user and/or lock the mobiledevice. In one example, the mobile ticketing application may be lockedand unlocked remotely by the ticket management server.

At 6110 the method includes rendering the ticket and displaying ticketcomponents based on display instructions. The ticket components mayinclude a 1 or 2 dimensional bar codes, text, images, animations, and/orvideo. In one example, the method 6100 may be implemented regardless ofnetwork connectivity of the mobile device. However, in another examplethe tickets may be unlaunchable if the mobile device does not havenetwork connectivity. In such an example, the mobile device is notlocked per se. However, the state of the ticket may be modified. Oncenetwork connectivity is re-established the mobile device may “phonehome” and the ticket may be usable again.

FIG. 62 shows a method 6200 for issuing citations via a mobile device ofa ticket inspector. The method 6200 may be implemented via the transitticket system described above with regard to FIGS. 1-55 or may beimplemented via other suitable transit ticket systems.

At 6202 the method includes inspecting tickets via visual review,barcode scan, and/or near field communication (NFC). This inspectionprocess determines whether a ticket is valid for a given person, date,time, and/or location. Additionally, it will be appreciated that thebarcode scan and NFC inspection may be implemented via a mobilecomputing device of a ticket inspector. It will be appreciated that themobile computing device may execute an inspector application.

At 6204 the method includes capturing the identity of the person's viadrivers license image capture, magnetic strip swipe, or manual capturingidentity via an inspector's mobile application. It will be appreciatedthat manual input may include typing the information into theapplication via a keyboard included in the device. In one example, theidentity information may be stored locally on the mobile deviceexecuting the inspector application. The stored identity information maybe used to provide a citation history and for synchronization with aticket management server.

At 6206 the method includes generating a citation using government formsand the captured identification information. It will be appreciated thatthe forms may be mandated via local and/or state governments. Thegenerated citation may be stored in the inspector's mobile computingdevice. In one example, the citation may be a uniform citation thatincludes the identification information captured via the inspectorapplication at steps 6204.

At 6208 the method include at the inspector's mobile application sendingthe citation information to an appropriate legal entity. The citationinformation may be sent via API's, periodic downloads, and/orintermediate batch processes. In one example, the citation informationmay be sent to a court system via a web-service.

At 6210 the method includes sending the citation information to a localprinter. In this way, all the parties may be provided with hard copiesof the citation information. In one example, the method may furtherinclude sending citation information to the ticket management server. Inthis way, citation data may be gathered for providing real timeanalytics.

In another example method, an inspector application may be used tosearch for users (e.g., riders) in a database to determine if a citationshould be issued. First, search criteria (e.g., partial names, names,phone number, and/or other unique identification data) may be enteredinto the inspector application to prompt display of the user's historyfor previous citations, warnings, and/or bans. Next, the inspector usingthe inspector application may review the results, if any are returned,and determine if a citation should be issued to the user. If it isdetermined that a citation should be issued the citation generationprocess may be implemented via the inspector application.

FIG. 63 shows a method 6300 for downloading a ticket. The method 6300may be implemented via the transit ticket system described above withregard to FIGS. 1-55 or may be implemented via other suitable transitticket systems.

At 6302 the method includes downloading, encrypting, and storing in adatabase, ticket information in a mobile device after completing aticket purchase process. This process may also be implemented atapplication refresh points such as a “pull-to-download” point and/orduring a login process. The ticket information may include ticketmeta-data.

At 6304 the method includes updating the server with the date/time,latitude, longitude, and/or application id associated with the device.It will be appreciated that step 6304 may be implemented after theticket information has been fully downloaded.

FIG. 64 shows a method 6400 for managing a transit ticket system. Themethod 6400 may be implemented via the transit ticket system describedabove with regard to FIGS. 1-55 or may be implemented via other suitabletransit ticket systems.

The method includes at 6402 downloading a mobile ticketing applicationfrom a ticket management server, the mobile ticketing applicationincluding a graphical data sheet, ticket dictionary, and ticket strings,the graphical data sheet including a plurality of rendered graphicalobjects corresponding to a plurality of different tickets. In this way,graphical data which may correspond to a plurality of ticket types maybe downloaded during installation of a rider application. As a result,the rider application has the information available to render a ticketwithout an extensive amount of additional data transfer between themobile computing device and the ticket management server. As a result,the efficiency of subsequent communication with the server may beincreased. Additionally, it will be appreciated that at least two of thegraphical objects included in the plurality of graphical objects areassociated with different types of tickets. Further in one example, theticket purchase process includes exchange of payment data with theticket management server. Further in one example, the ticket dictionarydetermines the position of graphical objects included in the graphicaldata sheet and the graphical data sheet includes animation sequences. Inone example, the ticket string includes instructions for animatinggraphical elements in the graphical data sheet. The instructions foranimation may include dynamic instructions related to velocity of anobject, fading of an object, path of an object, rotation of a object,brightness of an object, resizing an object, geometry of an object,object color, etc. In another example, the ticket strings includes colordata, transparency data, and scale data related to the graphicalelements in the graphical data sheet.

At 6404 the method includes receiving ticket rendering instructions fromthe ticket management server in response to completion of a ticketpurchase process via the mobile computing device. The ticket renderinginstructions may include data, command, etc., for selecting graphicalobjects in the graphical data sheet.

Next at 6406 the method includes rendering for display an active ticketon the mobile computing device with data stored on the mobile computingdevice based on the ticket rendering instructions, the graphical datasheet, ticket dictionary, and ticket strings in response to anactivation input command. It will be appreciated that the activationinput command may be a command initiated by a user via interaction withthe mobile computing device. For example, the user may select an“activate” or “use” button on a touch interface. Additionally, renderingan active ticket for display may include selecting one or more graphicalobjects for display from the plurality of rendered graphical objects, inone example.

At the ticket management server the method includes at 6408automatically sending updates of one or more of the graphical datasheet, ticket dictionary data, and ticket string at predetermined timeintervals to the mobile computing device independent of ticket purchaseprocesses implemented by the mobile computing device. In one example,automatically sending updates includes adding, overwriting, or deletingdata in the graphical data sheet, ticket dictionary, or ticket strings.In this way the ticketing graphics may be updated regardless of ticketpurchase or activation. As a result, the reliability of the ticketinggraphics updates is increased. Further in one example, rendering theactive ticket includes selecting one or more graphical objects fordisplay from the plurality of rendered graphical objects. Still furtherin another example, the selected graphical objects are layered fordisplay.

FIG. 65 shows a method 6500 for gathering analytic information from atransit ticket system. The method 6500 may be implemented via thetransit ticket system described above with regard to FIGS. 1-55 or maybe implemented via other suitable transit ticket systems.

At 6502 the method includes gathering ticket user data via a ticketmanagement server in communication with a plurality of mobile computingdevices executing a mobile ticketing application. At 6504 the methodincludes generating analytical ticket data based on the ticket use data,the analytical ticket data including one or more of total ticket sales,total number of riders, peak ridership, base ridership, averageridership, ridership percentage trends, number of approved tickets, mostactivated ticket type, frequency of ticket activation, time of activatedtickets, new system users, or location of activated ticket. Next at 6506the method includes at the ticket management server, displaying theanalytical ticket data in an analytic dashboard. In one example, theticket user data is gathered in real time. Further in one example, theanalytical ticket data is applied to a map. In such an example the mapmay be a heat map. Still further in one example, the analytical ticketdata is further gathered from a plurality of ticket inspection mobilecomputing devices. In one example, the analytic data may be manipulatedin real-time using on screen interactive tools such as time sliders,data picker, and metadata drop down. Additionally in one example, theanalytic data applied to the map may be manipulated in real-time to showdifferent rider and ticket types over a chosen period of time.

Further in one example, the analytic data, after chosen time frames andmeta factorings, may be exported in multiple data formats. Still furtherin one example, the analytic data may be rendered in different styles ofgraph chosen by the user. In another example, the analytic data may beviewed in selected time/date ranges such as a week over week, month overmonth, year over year view, etc. Further in one example, the analyticdata presented on a map may show points of interest and nearest transitstop data. In another example, the analytic data on a map may beanimated through chosen date range to show user activity over timevisually.

Further in one example, the analytic data may be sorted based on columnvalue. In another example, the analytic data may be filtered byon-screen selections. Still further in another example, the analyticdata may be drilled down into by interacting with the display. In thisway, the analytic data may be viewed an manipulated in a variety ofways. Enabling a user of the analytic dashboard to easily comprehend theanalytic data as well as quickly and efficiently manipulate the analyticdata according to their predilection.

FIG. 66 shows an example graphical user interface 6600 executed via aninspector application on a mobile computing device in the transit ticketsystem. It will be appreciated that the inspector application mayrequire a pin, password, username, email, etc., to access theapplication. If an incorrect pin, password, username, etc., is enteredaccessed to the inspector application is denied. The pin, password,username, etc., may be checked by user management backend in the ticketmanagement server. In this way, it is assured that a user of theinspector application has sufficient privileges. In one example,privileges may be added and/or revoked through the user managementbackend in the ticket management server. Specifically in one example,the inspector application may be locked in the case of revokedprivileges.

The mobile computing device executing the inspector application mayreceive ticket information via a camera, a laser scan, near fieldcommunication (NFC), Bluetooth, airdrop, etc. Specifically, in oneexample the device executing the inspector application may be configuredto input the ticket information via camera, NFC, and Bluetooth. In thisway, a variety of techniques may be used to gather ticket information,thereby expanding the device's capabilities. The location and time ofthe mobile device executing the inspector application may be determinedand stored or otherwise recorded when the ticket information isreceived. Thus, ticket information (e.g., ticket tokens) may be scannedor otherwise uploaded into the device executing the inspectorapplication. After the inspector application receives the ticketinformation (e.g., token data) the application may decrypt and parse theticket information (e.g., token data) and may send this information tothe ticket management server for validation. The information may be sentto the server in real-time, in one example. Additionally, the time andlocation data of the scan or information upload may also be sent to theticket management server. In this way, ticket analytics may be gatheredvia the transit ticket system. Additionally or alternatively, theinspector application may locally determine token validity.

FIG. 67 shows another example graphical user interface 6700 executed viaan inspector application on a mobile computing device in the transitticket system. Token information and server validation check isdisplayed via the user of the inspector application after the ticketmanagement server decrypts and parses token data and/or token validityis locally determined via the inspector application. The tokeninformation and server validation check is displayed to enable a user ofthe inspector application to make a determination on the validity of thetoken. The token information may include a serial number, token type,and/or data from the medium presenting the token.

After the token data is displayed, the mobile computing device maysynchronize scan data or other uploaded ticket information with theticket management server. In one example, this synchronization may beimplemented in real time. Additionally, the inspector application maysupport local and server-side blacklisting to flag accounts, tokens,and/or other data points specific to a token. Additionally, a visualelement 6702 indicates the status of the token check. In one example,the inspector application is configured to constantly refresh. However,when the inspector application looses network connectivity, a refreshrequest, and/or other data slated to be sent to the server may be storedlocally.

FIG. 68 shows another example graphical user interface 6800 executed viaan inspector application on a mobile computing device in the transitticket system. As shown, the inspector application detects and displayserror information when an invalid barcode is scanned, displaying anerror message. A description of the invalidity of the scanned barcodemay be displayed. It will be appreciated that other token informationmay be invalidated, in other examples.

In an example method for inspecting a ticket (e.g., checking a ticketsvalidity) first a token stored in a rider application may be scanned orotherwise uploaded (e.g., NFC, Bluetooth, picture upload) to aninspector application. Next, the token may be synced to the backend viathe inspector application. Syncing to the backend may include sendingtoken information to a ticket management server. Next, the validity ofthe token information may be checked via the ticket management serverand/or the inspector application. Next, validity informationcorresponding to the ticket may be presented via the inspectorapplication. It will be appreciated that the ticket management servermay send validity data to the inspector application prior topresentation of the validity information. Next, the token and other datauploaded to the inspector application are stored in the inspector'sdevice via the inspector application. In one example, the inspectorapplication may access the stored data via a graphical user interface.The stored data presented in the graphical user interface may includethe type of token that was scanned (e.g., adult/youth, 2-hour/1 day,etc.), the token' status (e.g., valid/invalid), token scan time, tokenscan location, etc. It will be appreciated that the token data displayedvia the inspector application may include alphanumeric symbols, images,graphics, animation, etc.

Further in one example, token lookup via the inspector application maybe supported through use of the token purchaser's account, such asmobile number, driver's license number, email address, and/or otheridentification information. Information provided by the account ownermay be displayed in the inspector application when looking up a token toallow positive identification of the person presenting the token vs. thetoken owner.

In one example, the inspector application may be configured to displayavailable tokens for a giver user in response to receiving tokeninformation. The token information may include a phone number, barcodedata, or other identification information uploaded via NFC, Bluetooth,manual input, a camera, a laser scan, etc.). Additionally, the uploadingaction executed via the inspector application may be logged by theticket management server (e.g., on the backend).

Still further in one example, the inspector application may be madeaware of the graphical layout, animation, color, etc., of valid tickets.In this way, another layer of ticket verification is provided in theticketing system.

FIG. 69 shows a process flow for managing tickets via multiple devices.It will be appreciated that the process flow shown in FIG. 69 may beimplemented via the transit ticket system described above with regard toFIGS. 1-55 and 66-68.

In the process flow 6900 shown in FIG. 69 tickets can only be stored onone device at a time. Thus, for a user wishing to use tickets onmultiple devices they may either purchase tickets on both devices ortransfer the tickets between the devices. At 6902 a ticket istransferred between two devices. In one example, a recall feature in theTOMS may be used to enable the ticket transfer. At 6904 tickets may beaccessed via a cloud computing network.

At 6906 tickets may be recalled via the TOMS. This feature allows a user(e.g., rider) to “remove” tickets from a device and make them availablefor download again. Recalling a ticket may be initiated and completed bythe user (e.g., rider) without the need for agency assistance, ifdesired. Recalling the tickets may include the following steps, first auser (e.g., rider) logs into their account via a network (e.g., theInternet) connected to the ticket management server and navigates to a“my tickets” interface. Next the user selects a “recall my unusedtickets” button. The mobile ticketing application (e.g., riderapplication) associated with the recalled tickets then becomes “locked”.The recalled ticket may become available again after a predeterminedperiod of time (e.g., 24 hours, 48 hours, 72 hours, etc.). Once thetickets are available for download the user can open the mobileticketing application via a device and select a “pull to refresh” buttonto download the tickets. It will be appreciated that the ticket may bedownloaded to another device executing the mobile ticketing application.In one example, if the user has a device with unused tickets they canbypass the aforementioned waiting period and immediately make thetickets available on the server by selecting a “pull to refresh” buttonon that device, in one example. The device will then be locked. Thelocked device may be unlocked through user selection of an unlockbutton. The unlock button may be presented in the same graphicalinterface as the pull to refresh button. After the device is unlockedthe tickets are available for download. Again, the user may log into themobile ticketing application and select a “pull to refresh button” todownload the recalled tickets. The user may access their account via anetwork browsing application to recall, replace, and/or transfer unusedtickets, in one example. The network browsing application may access theuser's account via the ticket management server.

At 6908 the user may obtain a new phone or other suitable mobilecomputing device. It the user has access to their old device, the usermay use the recall method at 6906 for ticket transfer. However, if theuser does not have access to their old phone the process flow proceedsto 6910. In one example, if the old device was lost the user may contactthe ticket issuer if they have existing tickets of value (e.g., unusedtickets, time left).

At 6910 the user installs a new mobile ticketing application on theirnew device. The application may have a new unique identification number.Next at 6912 the process flow includes retrieving missing tickets. Themissing ticket may be retrieved via the user selecting the “pull torefresh” button on the mobile ticketing application. In response toselection of the “pull to refresh” button it is determined if the userhas any unused tickets. If the user does have unused tickets, theprocess flow proceeds to 6906 where the ticket recalling steps areimplemented. However, if the user does not have any unused tickets acourtesy ticket may be issued at 6914. The courtesy ticket may be issuedby the TOMS. The user may contact an administrator in the TOMS torequest a courtesy ticket, in one example. In one example, the user maysend a courtesy ticket request to the TOMS through a refund interface.In one example, if the user has an active ticket that still has value(e.g., a 30 day ticket, a 1 year ticket) the user may request a courtesyticket. However, if the courtesy ticket request is denied the user maypurchase a ticket at 6916.

FIG. 70 shows a graphical user interface 7000 executed via a mobileticketing application on a mobile computing device in the transit ticketsystem. A “pull to refresh” button is shown at 7002. It will beappreciated, that the “pull to refresh” button may be selected by a userto download ticket which were previously purchased via a networkbrowsing application. For instance, a user may purchase tickets via adesktop computing device through a web-browser and then access a mobileticketing application via their mobile device and select “pull torefresh” to download the purchased tickets to their mobile device. Inthis way, a user may prompt ticket download via their mobile device.However, in other examples the tickets may be automatically downloadedto the mobile device in response to ticket purchase.

FIG. 71 shows a process flow 7100 for purchasing a ticket via a networkbrowsing application and downloading the purchased tickets via a mobiledevice. The process flow 7100 may be implemented via the transit ticketsystem, described above. The browsing application may be executed via adesktop computing device or other suitable computing device. At adesktop application the user may add tickets to a shopping cart. Theuser may proceed to checkout if they are logged in. However, if they arenot logged in they are prompted to register. Registration may includecreating an account via a network site. After the user selects checkoutthe user may enter new payment card information or select stored paymentcard information. If the payment card information fails to be acceptedthe user will be notified. However, if the payment card information isaccepted the purchased tickets are made available for download. Next,the mobile device downloads the available tickets via selection of a“pull to refresh” button. In response to selection of the “pull torefresh” button tickets will be marked downloaded. However, if a user innot logged into the mobile ticketing application executed on the mobiledevice the user may be prompted to login. In one example, tickets may beautomatically downloaded in response to login.

FIG. 72 shows an example ticket designer interface 7200 which may begenerated via a ticket designer in ticket management server. In oneexample, a user of the ticket designer interface may be initiallypresented with a blank canvas from which they can load previous ticketsand/or create a new ticket. As shown, the user may be given numerousoptions to navigate the creation of a ticket. For example, ticket layersmay be selected to be added to the ticket. The example ticket layersshown in FIG. 72 include background, city, clouds, bridge, andstreetcar. However, numerous types of layers have been envisaged. Asshown, a user can select the position (e.g., x-y coordinates) of each ofthe layers. Additionally, a plurality of previously created tickets maybe presented in the interface. Furthermore, the color of the layersand/or specific objects in the layers may be selected via a colorpicker. The color picker may enable a user to enter numerical RGB valuesor select a RGB value in a graphical plot. The ticket design interfacemay also enable a user to modify the timeline of ticket animations.

As shown, a user may work in a tapped mode and an untapped mode. Thetapped mode may show an intended graphical configuration of the ticketwhen the ticket is selected for use via the mobile ticketingapplication. On the other hand, the untapped mode shows an intendedgraphical configuration of the ticket when the ticket has not beenselected for use. In this way, a designer can quickly view differentstates of the ticket. It will be appreciated that the ticket designermay store and retrieve data from a rules engine, described in greaterdetail herein with regard to FIG. 73.

FIG. 73 shows a depiction of the functionalities of the rules engine7300. The rules engine 7300 may be executed via the ticket managementserver discussed above. The rules engine may receive ticket informationfrom a ticket designer program. The ticket information may include agraphical data sheet (e.g., a spritesheet), a ticket dictionary, and/orticket objects. The rules engine may also communicate with the mobiledevice to switch tickets according to a schedule.

Additionally, the mobile ticketing application may communicate with therules engine to request metadata in response to application launch,application wake-up, and/or application pause. In response to a metadatarequest the rules engine sends metadata to the mobile ticketingapplication. The device state may be updated to the current ticket inresponse to receiving the metadata. Additionally, a TOMS scheduler maysend a ticketing schedule to the rules engine. The ticketing schedulemay define the time period when the graphical data sheets (e.g.,spritesheets) and ticket dictionary are to be used. In this way, theticket scheduler coordinates data with the rules engine regarding whento release a new ticket design. Furthermore, the mobile device mayperiodically check the rules engine to see if ticket data has beenupdated via the ticket designer.

It will be appreciated that each of the computing devices describedabove with regard to FIGS. 1-73 may include code stored in memoryexecutable by a processor configured to implement various instructionssuch as the methods, processes, etc., described herein. The memoryincludes storage devices with one or more of the followingcharacteristics: volatile, nonvolatile, dynamic, static, read/write,read-only, random access, sequential access, location addressable, fileaddressable, and content addressable. In some embodiments, the memoryand the processor may be integrated into one or more common devices,such as an application specific integrated circuit or a system on achip. Example computing devices include desktop computing devices andmobile computing devices (e.g., smartphones, tablets, laptops, etc.).Further it will be appreciated that the computing device may includedisplays for presenting graphical data described above.

It is to be understood that the configurations and/or approachesdescribed herein are exemplary in nature, and that these specificembodiments or examples are not to be considered in a limiting sense,because numerous variations are possible. The specific routines ormethods described herein may represent one or more of any number ofprocessing strategies. As such, various acts illustrated may beperformed in the sequence illustrated, in other sequences, in parallel,or in some cases omitted. Likewise, the order of the above-describedprocesses may be changed.

The subject matter of the present disclosure includes all novel andnon-obvious combinations and sub-combinations of the various processes,systems and configurations, and other features, functions, acts, and/orproperties disclosed herein, as well as any and all equivalents thereof.

1.-20. (canceled)
 21. A mobile ticketing application of a transit ticketsystem for executing on a mobile computing device in communication witha ticket management server, the mobile ticketing application comprising:(i) a user interface configured to facilitate purchases, by a user ofthe mobile computing device, of transit tickets from the ticketmanagement server, wherein the purchased transit tickets are associatedwith an account for the user of the mobile computing device; (ii) aticket library populated with any unused tickets associated with theuser's account that were purchased either via the ticket purchasefunction or by, or on behalf of, the user via a separate computer incommunication with the ticket management server, wherein, upon apurchase, the mobile ticketing application receives and stores mobileticket rendering instructions transmitted from the ticket managementserver; and (iii) a user interface configured to validate an unusedticket from the ticket library upon receiving a prompt by the user todisplay at least one of a visually-validated ticket and a QR code,wherein the user interface dynamically renders the visually-validatedticket by applying the ticket rendering instructions to a graphicaldatasheet to display certain graphical objects from the graphicaldatasheet selected by the ticket rendering instructions, and the mobileticketing application downloads the graphical datasheet and updates tothe graphical datasheet from the ticket management server independentlyof the purchase of the ticket being validated.
 22. The mobile ticketingapplication of claim 21, wherein at least two graphical objects from thegraphical datasheet are associated with different types of tickets. 23.The mobile ticketing application of claim 21, wherein the ticketmanagement server additionally transmits ticket dictionary data and aticket string, and updates to the ticket dictionary and ticket string,to the mobile computing device independent of ticket purchase processesimplemented by the mobile computing device.
 24. The mobile ticketingapplication of claim 21, wherein purchasing a ticket includes exchangeof payment data with the ticket management server.
 25. The mobileticketing application of claim 21, wherein the mobile ticketingapplication downloads a ticket string from the ticket management server,which includes instructions for animating graphical elements in thegraphical datasheet.
 26. The mobile ticketing application of claim 25,where the ticket strings includes color data, transparency data, andscale data related to the graphical elements in the graphical datasheet.
 27. The mobile ticketing application of claim 25, wherein thegraphical datasheet includes animated graphical objects.
 28. The mobileticketing application of claim 21, wherein the user interface isconfigured to display a visually validated ticket and a QR coderepresentation of the ticket.
 29. The mobile ticketing application ofclaim 21, wherein the user interface is configured to receive a userselection to validate a selected ticket as a visually validated ticketor as a QR code representation of the ticket.
 30. A method of managingvalidation of tickets via a mobile ticketing application incommunication with a ticket management server, comprising: in responseto requests from a user of a mobile computing device, purchasing transittickets from the ticket management server, wherein the purchased transittickets are associated with an account for the user of the mobilecomputing device; populating a ticket library with any unused ticketsassociated with the user's account that were purchased either via themobile computing device or by, or on behalf of, the user via a separatecomputer in communication with the ticket management server, wherein,upon a purchase, the mobile ticketing application receives and storesmobile ticket rendering instructions transmitted from the ticketmanagement server; and upon receiving a prompt by the user to display atleast one of a visually-validated ticket and a QR code, dynamicallyrendering the visually-validated ticket by applying the ticket renderinginstructions to a graphical datasheet to display at least one graphicalobject from the graphical datasheet specified by the ticket renderinginstructions, wherein the mobile ticketing application downloads thegraphical datasheet and updates to the graphical datasheet from theticket management server independently of the purchase of the ticketbeing validated.
 31. The method of claim 30, wherein at least twographical objects from the graphical datasheet are associated withdifferent types of tickets.
 32. The method of claim 30, wherein themobile ticketing application additionally downloads from the ticketmanagement server ticket dictionary data and a ticket string, andupdates to the ticket dictionary and ticket string, independent ofticket purchase processes implemented by the mobile computing device.33. The method of claim 30, wherein purchasing a ticket includesexchange of payment data with the ticket management server.
 34. Themethod of claim 30, wherein the mobile ticketing application downloads aticket string from the ticket management server, which includesinstructions for animating graphical elements in the graphicaldatasheet.
 35. The method of claim 34, wherein the ticket stringsincludes color data, transparency data, and scale data related to thegraphical elements in the graphical data sheet.
 36. The method of claim34, wherein the graphical datasheet includes animated graphical objects.37. The method of claim 30, further comprising displaying a visuallyvalidated ticket and a QR code representation of the ticket.
 38. Themethod of claim 30, further comprising receiving a user selection tovalidate a selected ticket as a visually validated ticket or as a QRcode representation of the ticket.